[レポート] サーバーレスアプリケーションを最適化しよう #reinvent #SRV401

こんにちは。サービスグループの武田です。

SRV401-R1 - [REPEAT 1] Optimizing Your Serverless Applications に参加してきましたのでレポートをお届けします。

セッション概要

Are you an experienced serverless developer? Do you want a handy guide for unleashing the full power of serverless architectures for your production workloads? Are you wondering whether to choose a stream or an API as your event source, or whether to have one function or many? In this session, we discuss architectural best practices, optimizations, and handy cheat codes that you can use to build secure, high-scale, high-performance serverless applications. We use real customer scenarios to illustrate the benefits.

アジェンダ

• Lambdaについて
• Lambdaの関数について
• Lambdaの実行環境について

セッションメモ

Lambdaについて

• 今日はLambdaにフォーカス
• Serverless applicationは次の要素がある
  • イベントソース
    • データの変更
    • エンドポイントへのリクエスト
    • リソースの変更
  • 関数
    • Node.js
    • Python
    • Java
    • C#
    • Go
  • サービス
    • いろいろ
• Lambda関数の内部
  • 関数
  • 言語ランタイム
  • 実行環境
  • コンピュータ基盤

このうちパフォーマンスに影響を与えられるのは関数と実行環境だけ。

Lambdaの関数について

• 構成要素
  • Handler() function
    • 関数呼び出し時に実行される
  • Event object
    • Lambda関数呼び出し時に送られるデータ
  • Context object
    • 実行時の情報へのアクセス
• 一時的なLambda関数の環境
  • Lambdaはプロセスごとにひとつのイベントを処理する
  • 注意として実行環境は再利用される
    • 変数の遅延ロードはグローバルスコープで行う
    • 軌道に影響を与えるため必要のないデータはロードしない
• Lambdaの環境変数とロジック
  • devやproductionなど複数の環境を作成するのに環境変数は有用
  • Lambdaのハンドラ（エントリポイント）とコアロジックは分割する
  • 関数ごとの値は環境変数を使用する
  • 関数またぎの値はパラメーターストアかシークレットマネージャーを使用する
  • 複雑な処理はオーケストレーションツールとしてStep Functionsを使用する
• プロジェクトとリポジトリ
  • MonorepoはFaaSではアンチパターン
  • 2つのプリンシパルに従う
    • 関数が1つのイベントソースを共有している場合は同じリポジトリに含めることができる。そうでないなら、別のアプリケーションとして別のリポジトリにする
    • 関数が1つのイベントソースを共有しているが、異なるパッケージをインポートしているなら別のファイルに分割する

Lambdaの実行環境について

• 関数のライフサイクル
  • AWSの最適化範囲
    • ダウンロード
    • 実行環境の開始
  • 開発者の最適化範囲
    • ランタイムの軌道
    • 実行コード

• X-Rayと統合されており、各呼び出しをトレースできる

• 関数のチューニングはメモリ制御のみ
  • それに伴い、CPUコアとネットワークキャパシティの割り当てが変化する
  • メモリ割り当てを変更することで、実行時間とコストを最適化できる

• Lambdaの実行モデル
  • 同期型（push）
    • API Gateway
  • 非同期型（event）
    • Amazon SNS
    • Amazon S3
  • Poll-base
    • Amazon DynamoDB
    • Amazon Kinesis
  • Lambda APIを直接呼ぶことも可能
  • レスポンスが不要なら非同期実行も可能

• クライアントに対して適切なエントリポイントを選択する
  • 1つのカスタムクライアント
    • AWS SDKを使用する
  • リージョン内のパブリックAPIのみ
    • API Gatewayによるリージョナルエンドポイントを使用する
  • VPC内のプライベートマイクロサービス
    • API Gatewayによるプライベートエンドポイントを使用する
  • カスタムインタフェースは必要ない
    • API Gatewayではないソースを使用する
• なるはやであるイベントのみを拾う
  • S3のEvent Prefix
  • SNSのMessage filtering
• 比較方法
  • Scale/Concurrency controls
  • Durability
  • Persistence
  • Consumption models
  • Retries
  • Pricing
• 今回はScale/Concurrency controls、Persistence、Retriesについて見てみる

• 関数の同時実行数の制御
  • デフォルトでは共有プールを使用する
  • 関数ごとに同時実行数の予約ができる
  • RDS接続時など、同時実行数の上限を設定することが重要なケースもある
  • 同時実行数を0にするとスロットリングできる

同時実行数の管理 - AWS Lambda

Scale/Concurrency controlsの詳細。

Persistenceの詳細。

Retry/failure handlingの詳細。

• LambdaのDead Letter Queueについて
  • デフォルトでは、非同期に実行され失敗した関数は2回再実行され、失敗したら破棄される
• 非同期呼び出しの場合必ず次の事項を有効にする
  • SQSのQueue長はメトリクスおよびアラームをモニタリングする
  • SNSを使っている場合、持続性と信頼性のあるエンドポイントを使用する
• これらをすることで、Dead Letter Queueが急増してもイベント情報は保存される

VPCが必要なケース。

• 基本的なVPCデザイン
  • 常に最低2つのAZで動作するようにする
  • Lambda関数が独自のサブネットで動作するようにする
  • Lambda関数を実行するサブネットはスケールするようIPレンジを大きくする
  • インターネット接続が必要な場合はNATを使用する
  • ENIsがつらいのは知っている
• Lambdaパーミッションモデル
  • 実行と呼び出しの両方に対するセキュリティ制御が必要
  • 実行ポリシー
    • どのAWSリソース/APIを呼べるかはIAMで制御する
    • ストリーミング実行される
  • 呼び出しポリシー
    • 同期呼び出しと非同期呼び出しされる
    • リソースポリシーによりクロスアカウントアクセスが可能となる
• AWS SAMを使うといいよ！

AWS サーバーレスアプリケーションモデル (AWS SAM) の使用 - AWS Lambda

まとめ

Lambdaはツールとしてちょっと使う分には簡単に使い始めることができますが、本番環境の運用では考慮しなければいけない点が多くあることがわかりました。実行環境のパフォーマンス最適化と、処理が失敗した場合の対応は特に大事なことですね。本番環境でLambdaを使用する際にはこれらのことを念頭に置いて開発していきましょう。

現場からは以上です。